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Abstract 


The Generalized MPLS (GMPLS) suite of protocols has been defined to 
control different switching technologies as well as different 
applications. These include support for requesting TDM connections 
including Synchronous Optical Network/Synchronous Digital Hierarchy 
(SONET/SDH) and Optical Transport Networks (OTNs). 


This document provides an evaluation of the IETF Routing Protocols 
against the routing requirements for an Automatically Switched 
Optical Network (ASON) as defined by ITU-T. 
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Les 


Introduction 


Certain capabilities are needed to support the ITU-T Automatically 
Switched Optical Network (ASON) control plane architecture as defined 
in [G.8080]. 


[RFC4258] details the routing requirements for the GMPLS routing 
suite of protocols to support the capabilities and functionality of 
ASON control planes identified in [G.7715] and in [G.7715.1]. The 
ASON routing architecture provides for a conceptual reference 
architecture, with definition of functional components and common 
information elements to enable end-to-end routing in the case of 
protocol heterogeneity and to facilitate management of ASON networks. 
This description is only conceptual: no physical partitioning of 
these functions is implied. 


However, [RFC4258] does not address GMPLS routing protocol 


applicability or capabilities. This document evaluates the IETF 
Routing Protocols against the requirements identified in [RFC4258]. 
The result of this evaluation is detailed in Section 5. Close 


examination of applicability scenarios and the result of the 
evaluation of these scenarios are provided in Section 6. 


ASON (Routing) terminology sections are provided in Appendices A and 
B. 


Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


The reader is expected to be familiar with the terminology introduced 
in [RFC4258]. 
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4. Requirements: Overview 


The following functionality is expected from GMPLS routing protocols 
to instantiate the ASON hierarchical routing architecture realization 
(see [G.7715] and [G.7715.1]): 


- Routing Areas (RAs) shall be uniquely identifiable within a 
carrier’s network, each having a unique RA Identifier (RA ID) 
within the carrier’s network. 


—- Within a RA (one level), the routing protocol shall support 
dissemination of hierarchical routing information (including 
summarized routing information for other levels) in support of an 
architecture of multiple hierarchical levels of RAs; the number of 
hierarchical RA levels to be supported by a routing protocol is 
implementation specific. 


- The routing protocol shall support routing information based on a 
common set of information elements as defined in [G.7715] and 
[G.7715.1], divided between attributes pertaining to links and 
abstract nodes (each representing either a sub-network or simply a 
node). [G.7715] recognizes that the manner in which the routing 
information is represented and exchanged will vary with the routing 
protocol used. 


- The routing protocol shall converge such that the distributed 
Routing DataBases (RDB) become synchronized after a period of time. 


To support dissemination of hierarchical routing information, the 
routing protocol must deliver: 


- Processing of routing information exchanged between adjacent levels 
of the hierarchy (i.e., Level N+1 and N), including reachability 
and (upon policy decision) summarized topology information. 


- Self-consistent information at the receiving level resulting from 
any transformation (filter, summarize, etc.) and forwarding of 
information from one Routing Controller (RC) to RC(s) at different 
levels when multiple RCs are bound to a single RA. 


- A mechanism to prevent re-introduction of information propagated 


into the Level N RA’s RC back to the adjacent level RA’s RC from 
which this information has been initially received. 
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Note: The number of hierarchical levels to be supported is routing 
protocol specific and reflects a containment relationship. 


Reachability information may be advertised either as a set of UNI 
Transport Resource address prefixes, or as a set of associated 
Subnetwork Point Pool (SNPP) link IDs/SNPP link ID prefixes, assigned 
and selected consistently in their applicability scope. The formats 
of the control plane identifiers in a protocol realization are 
implementation specific. Use of a routing protocol within a RA 
should not restrict the choice of routing protocols for use in other 
RAs (child or parent). 


As ASON does not restrict the control plane architecture choice, 
either a co-located architecture or a physically separated 
architecture may be used. A collection of links and nodes, such as a 
sub-network or RA, must be able to represent itself to the wider 
network as a single logical entity with only its external links 
visible to the topology database. 


5. Evaluation 


This section evaluates support of existing IETF routing protocols 
with respect to the requirements summarized from [RFC4258] in Section 
4. Candidate routing protocols are Interior Gateway Protocol (IGP) 
(OSPF and Intermediate System to Intermediate System (IS-IS)) and 
BGP. The latter is not addressed in the current version of this 
document. BGP is not considered a candidate protocol mainly because 
of the following reasons: 


- Non-support of TE information exchange. Each BGP router advertises 
only its path to each destination in its vector for loop avoidance, 
with no costs or hop counts; each BGP router knows little about 
network topology. 


- BGP can only advertise routes that are eligible for use (local RIB) 
or routing loops can occur; there is one best route per prefix, and 
that is the route that is advertised. 

- BGP is not widely deployed in optical equipment and networks. 

5.1. Terminology and Identification 

- Pi is a physical (bearer/data/transport plane) node. 

- Li is a logical control plane entity that is associated to a single 
data plane (abstract) node. The Li is identified by the TE 


Router_ID. The latter is a control plane identifier defined as 
follows: 
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[RFC3630]: Router_Address (top level) TLV of the Type 1 TE LSA 
[RFC3784]: Traffic Engineering Router ID TLV (Type 134) 


Note: This document does not define what the TE Router ID is. This 
document simply states the use of the TE Router ID to identify Li. 
[RFC3630] and [RFC3784] provide the definitions. 


- Ri is a logical control plane entity that is associated to a 
control plane "router". The latter is the source for topology 
information that it generates and shares with other control plane 
"routers". The Ri is identified by the (advertising) Router_ID 


[RFC2328]: Router ID (32-bit) 
[RFC1195]: IS-IS System ID (48-bit) 


The Router_ID, which is represented by Ri and which corresponds to 
the RC_ID [RFC4258], does not enter into the identification of the 
logical entities representing the data plane resources such as 
links. The Routing DataBase (RDB) is associated to the Ri. Note 
that, in the ASON context, an arrangement consisting of multiple 
Ris announcing routing information related to a single Li is under 
evaluation. 


Aside from the Li/Pi mappings, these identifiers are not assumed to 
be in a particular entity relationship except that the Ri may have 


multiple Lis in its scope. The relationship between Ri and Li is 
simple at any moment in time: an Li may be advertised by only one Ri 
at any time. However, an Ri may advertise a set of one or more Lis. 


Thus, the routing protocol MUST be able to advertise multiple TE 
Router IDs (see Section 5.7). 


Note: Si is a control plane signaling function associated with one or 
more Lis. This document does not assume any specific constraint on 
the relationship between Si and Li. This document does not discuss 
issues of control plane accessibility for the signaling function, and 
it makes no assumptions about how control plane accessibility to the 
Si is achieved. 


5.2. RA Identification 


G.7715.1 notes some necessary characteristics for RA identifiers, 
e.g., that they may provide scope for the Ri, and that they must be 
provisioned to be unique within an administrative domain. The RA ID 
format itself is allowed to be derived from any global address space. 
Provisioning of RA IDs for uniqueness is outside the scope of this 
document. 
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Under these conditions, GMPLS link state routing protocols provide 
the capability for RA Identification without further modification. 


5.3. Routing Information Exchange 


In this section, the focus is on routing information exchange Ri 
entities (through routing adjacencies) within a single hierarchical 
level. Routing information mapping between levels require specific 
processing (see Section 5.5). 


The control plane does not transport Pi identifiers, as these are 
data plane addresses for which the Li/Pi mapping is kept (link) 
local; see, for instance the transport LMP document [RFC4394] where 
such an exchange is described. Example: The transport plane 
identifier is the Pi (the identifier assigned to the physical 
element) that could be, for instance, "666B.F999.AF10.222C", whereas 
the control plane identifier is the Li (the identifier assigned by 
the control plane), which could be, for instance, "192.0.2.1". 


The control plane exchanges the control plane identifier information, 
but not the transport plane identifier information (i.e., not 
"666B.F999.AF10.222C", but only "192.0.2.1"). The mapping Li/Pi is 
kept local. So, when the Si receives a control plane message 
requesting the use of "192.0.2.1", Si knows locally that this 
information refers to the data plane entity identified by the 
transport plane identifier "666B.F999.AF10.222C". 


Note also that the Li and Pi addressing spaces may be identical. 
The control plane carries: 


1) its view of the data plane link end-points and other link 
connection end-points. 


2) the identifiers scoped by the Lis, i.e., referred to as an 
associated IPv4/IPv6 addressing space. Note that these 
identifiers may be either bundled TE link addresses or component 
link addresses. 


3) when using OSPF or ISIS as the IGP in support of traffic 
engineering, [RFC3477] RECOMMENDS that the Li value (referred to 
the "LSR Router ID") be set to the TE Router ID value. 


Therefore, OSPF and IS-IS carry sufficient node identification 
information without further modification. 
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5.3.1. Link Attributes 


[RFC4258] provides a list of link attributes and characteristics that 
need to be advertised by a routing protocol. All TE link attributes 
and characteristics are currently handled by OSPF and IS-IS (see 
Table 1) with the exception of Local Adaptation support. Indeed, 
GMPLS routing does not currently consider the use of dedicated TE 
link attribute(s) to describe the cross/inter-layer relationships. 


In addition, the representation of bandwidth requires further 
consideration. GMPLS Routing defines an Interface Switching 
Capability Descriptor (ISCD) that delivers information about the 
(maximum/ minimum) bandwidth per priority of which an LSP can make 
use. This information is usually used in combination with the 
Unreserved Bandwidth sub-TLV that provides the amount of bandwidth 
not yet reserved on a TE link. 


In the ASON context, other bandwidth accounting representations are 
possible, e.g., in terms of a set of tuples <signal_type; number of 
unallocated timeslots>. The latter representation may also require 
definition of additional signal types (from those defined in 
[RFC3946]) to represent support of contiguously concatenated signals, 
i.e., STS-—(3xN)c SPE / VC-4-Nc, N = 4, 16, 64, 256. 


However, the method proposed in [RFC4202] is the most straightforward 
without requiring any bandwidth accounting change from an LSR 
perspective (in particular, when the ISCD sub-TLV information is 
combined with the information provided by the Unreserved Bandwidth 
sub-TLV) . 
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Diversity Support 


Evaluation of Routing Protocols against ASON October 2006 


GMPLS OSPF 

Link-local part of the TE link identifier 
sub-TLV [RFC4203] 

Link remote part of the TE link identifier 
sub-TLV [RFC4203] 

Technology specific part of the Interface 
Switching Capability Descriptor sub-TLV 
[RFC4203] 

TE metric sub-TLV [RFC3630] 
Administrative Group sub-TLV [RFC3630] 
Switching Capability field part of the 
Interface Switching Capability Descriptor 
sub-TLV [RFC4203] 

Unreserved bandwidth sub-TLV [RFC3630] 
Max LSP Bandwidth part of the Interface 
Switching Capability Descriptor sub-TLV 
[RFC4203] 

Link Protection sub-TLV [RFC4203] 

SRLG sub-TLV [RFC4203] 


Local Adaptation support See above 


Table 1. 
Link Characteristics 
Local SNPP link ID 
Remote SNPP link ID 
Signal Type 
Link Weight 


Resource Class 
Local Connection Types 


Link Capacity 


Link Availability 
Diversity Support 


TE link attributes in GMPLS OSPF-TE 


GMPLS IS-IS 

Link-local part of the TE link identifier 
sub-TLV [RFC4205] 

Link-remote part of the TE link identifier 
sub-TLV [RFC4205] 

Technology specific part of the Interface 
Switching Capability Descriptor sub-TLV 
[RFC4205] 

TE Default metric [RFC3784] 
Administrative Group sub-TLV [RFC3784] 
Switching Capability field part of the 
Interface Switching Capability Descriptor 
sub-TLV [RFC4205] 

Unreserved bandwidth sub-TLV [RFC3784] 
Max LSP Bandwidth part of the Interface 
Switching Capability Descriptor sub-TLV 
[RFC4205] 

Link Protection sub-TLV [RFC4205] 

SRLG sub-TLV [RFC4205] 


Local Adaptation support See above 


Table 2. 


et al. 


TE link attributes in GMPLS IS-IS-TE 
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Note: Link Attributes represent layer resource capabilities and 
their utilization i.e. the IGP should be able to advertise these 
attributes on a per-layer basis. 


5.3.2. Node Attributes 


Node attributes are the "Logical Node ID" (described in Section 5.1) 
and the reachability information described in Section 5.3.3. 


5.3.3. Reachability Information 


Advertisement of reachability can be achieved using the techniques 
described in [OSPF-NODE], where the set of local addresses are 
carried in an OSPF TE LSA node attribute TLV (a specific sub-TLV is 
defined per address family, e.g., IPv4 and IPv6). However, 
[OSPF-NODE] is restricted to advertisement of Host addresses and not 
prefixes, and therefore it requires enhancement (see below). Thus, 
in order to advertise blocks of reachable address prefixes a 
summarization mechanism is additionally required. This mechanism may 
take the form of a prefix length (which indicates the number of 
significant bits in the prefix) or a network mask. 


A similar mechanism does not exist for IS-IS. Moreover, the Extended 
IP Reachability TLV [RFC3784] focuses on IP reachable end-points 
(terminating points), as its name indicates. 


5.4. Routing Information Abstraction 


G.7715.1 describes both static and dynamic methods for abstraction of 
routing information for advertisement at a different level of the 
routing hierarchy. However, the information that is advertised 
continues to be in the form of link and node advertisements 
consistent with the link state routing protocol used at that level. 
Hence, no specific capabilities need to be added to the routing 
protocol beyond the ability to locally identify when routing 
information originates outside of a particular RA. 


The methods used for abstraction of routing information are outside 
the scope of GMPLS routing protocols. 


5.5. Dissemination of Routing Information in Support of Multiple 
Hierarchal Levels of RAs 


G.7715.1 does not define specific mechanisms to support multiple 

hierarchical levels of RAs beyond the ability to support abstraction 
as discussed above. However, if RCs bound to adjacent levels of the 
RA hierarchy are allowed to redistribute routing information in both 
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directions between adjacent levels of the hierarchy without any 
additional mechanisms, they would not be able to determine looping of 
routing information. 


To prevent this looping of routing information between levels, IS-IS 
[RFC1195] allows only advertising routing information upward in the 
level hierarchy and disallows the advertising of routing information 
downward in the hierarchy. [RFC2966] defines the up/down bit to 
allow advertising downward in the hierarchy the "IP Internal 
Reachability Information" TLV (Type 128) and "IP External 
Reachability Information" TLV (Type 130). [RFC3784] extends its 
applicability for the "Extended IP Reachability" TLV (Type 135). 
Using this mechanism, the up/down bit is set to 0 when routing 
information is first injected into IS-IS. If routing information is 
advertised from a higher level to a lower level, the up/down bit is 
set to 1, indicating that it has traveled down the hierarchy. 
Routing information that has the up/down bit set to 1 may only be 
advertised down the hierarchy, i.e., to lower levels. This mechanism 
applies independently of the number of levels. However, this 
mechanism does not apply to the "Extended IS Reachability" TLV (Type 
22) used to propagate the summarized topology (see Section 5.3), 
traffic engineering information as listed in Table 1, as well as 
reachability information (see Section 5.3.3). 


OSPFv2 [RFC2328] prevents inter-area routes (which are learned from 
area 0) from being passed back to area 0. However, GMPLS makes use 
of Type 10 (area-local scope) LSAs to propagate TE information 
[RFC3630], [RFC4202]. Type 10 Opaque LSAs are not flooded beyond the 
borders of their associated area. It is therefore necessary to have 
a means by which Type 10 Opaque LSA may carry the information that a 
particular piece of routing information has been learned from a 
higher-level RC when propagated to a lower-level RC. Any downward RC 
from this level, which receives an LSA with this information would 
omit the information in this LSA and thus not re-introduce this 
information back into a higher-level RC. 


5.6. Routing Protocol Convergence 


Link state protocols have been designed to propagate detected 
topological changes (such as interface failures and link attributes 
modification). The convergence period is short and involves a 
minimum of routing information exchange. 


Therefore, existing routing protocol convergence involves mechanisms 
that are sufficient for ASON applications. 
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5.7. Routing Information Scoping 


The routing protocol MUST support a single Ri advertising on behalf 
of more than one Li. Since each Li is identified by a unique TE 
Router ID, the routing protocol MUST be able to advertise multiple TE 
Router IDs. That is, for [RFC3630], multiple Router Addresses and 
for [RFC3784] multiple Traffic Engineering Router Ids. 


The Link sub-TLV that is currently part of the top level Link TLV 
associates the link to the Router_ID. However, having the Ri 
advertising on behalf of multiple Lis creates the following issue, as 
there is no longer a 1:1 relationship between the Router_ID and the 
TE Router_ID, but a 1:N relationship is possible (see Section 5.1). 
As the link-local and link-remote (unnumbered) ID association may not 
be unique per abstract node (per Li unicity), the advertisement needs 
to indicate the remote Lj value and rely on the initial discovery 
process to retrieve the {Li;Lj} relationship(s). In brief, as 
unnumbered links have their ID defined on per Li bases, the remote Lj 
needs to be identified to scope the link remote ID to the local Li. 
Therefore, the routing protocol MUST be able to disambiguate the 
advertised TE links so that they can be associated with the correct 
TE Router ID. 


Moreover, when the Ri advertises on behalf multiple Lis, the routing 
protocol MUST be able to disambiguate the advertised reachability 
information (see Section 5.3.3) so that it can be associated with the 
correct TE Router ID. 


6. Evaluation Scenarios 


The evaluation scenarios are the following; they are respectively 
referred to as cases 1, 2, 3, and 4. 


In Figure 1, below, 
- R3 represents an LSR with all components collocated. 


- R2 shows how the "router" component may be disjoint from the node. 
- R1 shows how a single "router" may manage multiple nodes. 
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|R1 | |R2 | 
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Figure 1. Evaluation Cases 1, 2, and 3 


Case 1 as represented refers either to direct links between edges or 
to "logical links" as shown in Figure 2 (or any combination of them). 


| | | | 
| ri | | E2 | 
Ne cel |, ee | 
|, RI] | +: R2| 
Control Plane ate +--- 
Elements : : 
ae Se Foe ee ree ge ey ig Pee FONT, ee eae ey Re 4+----------- - - YH OO 
Data Plane 
Elements 
----—+ aaa SoS eee ee SS ee eS SS ee + en 
i> pees | ? |---------- it 
a | --- | Rea 
aa | | 
oe: emer hea i 


Figure 2. Case 1 with Logical Links 
Another case (referred to as Case 4) is constituted by the Abstract 


Node as represented in Figure 3. There is no internal structure 
associated (externally) to the abstract node. 
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EJ 
A 


Control Plane 


Data Plane 


Figure 3. Case 4: Abstract Node 


Note: the "signaling function" referred to as Si, i.e., the control 
plane entity that processes the signaling messages, is not 
represented in these figures. 


7. Summary of Necessary Additions to OSPF and IS-IS 


The following sections summarize the additions to be provided to OSPF 
and IS-IS in support of ASON routing. 


7.1. OSPFv2 


Reachability Extend Node Attribute sub-TLVs to support address 
prefixes (see Section 5.3.3). 


Link Attributes Representation of cross/inter-layer relationships 
in link top-level link TLV (see Section 5.3.1). 


Optionally, provide for per-signal-type bandwidth 
accounting (see Section 5.3.1). 


Scoping TE link advertisements to allow for retrieving 
their respective local-remote TE Router_ID 
relationship (s) (see Section 5.7). 


Prefixes part of the reachability advertisement 
(using Node Attribute top-level TLV) needs to be 
associated to its respective local TE Router_ID 
(see Section 5.7). 
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Hierarchy Provide a mechanism by which Type 10 Opaque LSA may 
carry the information that a particular piece of 
routing information has been learned from a 
higher-level RC when propagated to a lower-level RC 
(so as not to re-introduce this information into a 
higher-level RC). 


Teza IS-IS 


Reachability Provide for reachability advertisement (in the form 
of reachable TE prefixes). 


Link Attributes Representation of cross/inter-layer relationships 
in Extended IS Reachability TLV (see Section 
De Sel). 


Optionally, provide for per-signal-type bandwidth 
accounting (see Section 5.3.1). 


Scoping Extended IS Reachability TLVs to allow for 
retrieving their respective local-remote TE 
Router_ID relationship(s) (see Section 5.7). 


Prefixes part of the reachability advertisement 
needs to be associated to its respective local TE 
Router_ID (see Section 5.7). 


Hierarchy Extend the up/down bit mechanisms to propagate the 
summarized topology (see Section 5.3) and traffic 
engineering information as listed in Table 1, as 
well as reachability information (see Section 
SSRS 


8. Security Considerations 


The introduction of a dynamic control plane to an ASON network 
exposes it to additional security risks that may have been controlled 
or limited by the use of management plane solutions. The routing 
protocols play a part in the control plane and may be attacked so 
that they become unstable or provide incorrect information for use in 
path computation or by the signaling protocols. 


Nevertheless, there is no reason why the control plane components 
cannot be secured, and the security mechanisms developed for the 
routing protocol and used within the Internet are equally applicable 
within an ASON context. 
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10. 


10. 


[RFC4258] describes the requirements for security of routing 
protocols for the Automatically Switched Optical Network. Reference 
is made to [M.3016], which lays out the overall security objectives 
of confidentiality, integrity, and accountability. These are well 
discussed for the Internet routing protocols in [THREATS]. 


A detailed discussion of routing threats and mechanisms that are 
currently deployed in operational networks to counter these threats 
is found in [OPSECPRACTICES]. A detailed listing of the device 
capabilities that can be used to support these practices can be found 
in [RFC3871]. 


Acknowledgements 
The authors would like to thank Adrian Farrel for having initiated 


the proposal of an ASON Routing Solution Design Team and the ITU-T 
SG15/Q14 for their careful review and input. 


References 

1. Normative References 

[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP 
and dual environments", RFC 1195, December 1990. 

[RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide 
Prefix Distribution with Two-Level IS-IS", RFC 
2966, October 2000. 

[RFC2328] Moy, J., “OSPF Version 2", STD 54, RFC 2328, April 
1998. 

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
Requirement Levels", BCP 14, RFC 2119, March 1997. 

[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered 
Links in Resource ReSerVation Protocol - Traffic 
Engineering (RSVP-TE)", RFC 3477, January 2003. 

[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic 
Engineering (TE) Extensions to OSPF Version 2", RFC 
3630, September 2003. 

[RFC3784] Smit, H. and T. Li, "Intermediate System to 


Intermediate System (IS-IS) Extensions for Traffic 
Engineering (TE)", RFC 3784, June 2004. 


Papadimitriou, et al. Informational [Page 15] 


RFC 4652 


[RFC3871] 


[RFC3946] 


[RFC4202] 


[RFC4203] 


[RFC4205] 


[RFC4258] 


Evaluat 


ion of Routing Protocols against ASON October 2006 


Jones, G., Ed., "Operational Security Requirements 
for Large Internet Service Provider (ISP) IP 
Network Infrastructure", RFC 3871, September 2004. 


Mannie, E. and D. Papadimitriou, "Generalized 
Multi-Protocol Label Switching (GMPLS) Extensions 
for Synchronous Optical Network (SONET) and 
Synchronous Digital Hierarchy (SDH) Control", RFC 
3946, October 2004. 


Kompella, K., Ed., and Y. Rekhter, Ed., "Routing 
Extensions in Support of Generalized Multi-Protocol 
Label Switching (GMPLS)", RFC 4202, October 2005. 


Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF 
Extensions in Support of Generalized Multi-Protocol 
Label Switching (GMPLS)", RFC 4203, October 2005. 


Kompella, K., Ed., and Y. Rekhter, Ed., 
"Intermediate System to Intermediate System (IS-IS) 
Extensions in Support of Generalized Multi-Protocol 
Label Switching (GMPLS)", RFC 4205, October 2005. 


Brungard, D., "Requirements for Generalized Multi- 
Protocol Label Switching (GMPLS) Routing for the 
Automatically Switched Optical Network (ASON)", RFC 
4258, November 2005. 


10.2. Informative References 


[RFC4394] 


[OPSECPRACTICES ] 


[OSPF-NODE] 


[THREATS ] 


Papadimitriou, 


et al. 


Fedyk, D., Aboul-Magd, O., Brungard, D., Lang, J., 
and D. Papadimitriou, "A Transport Network View of 
the Link Management Protocol (LMP)", RFC 4394, 
February 2006. 


Kaeo, M., "Operational Security Current Practices", 
Work in Progress, July 2006. 


Aggarwal, R. and K. Kompella, "Advertising a 
Router’s Local Addresses in OSPF TE Extensions", 
Work in Progress, June 2006. 


Barbir, A., Murphy, S., and Y. Yang, "Generic 


Threats to Routing Protocols", RFC 4593, October 
2006. 


Informational [Page 16] 


RFC 4652 Evaluation of Routing Protocols against ASON October 2006 


For information on the availability of ITU Documents, please see 
http://www.itu.int 


[G.7715] ITU-T Rec. G.7715/Y.1306, "Architecture and 
Requirements for the Automatically Switched Optical 
Network (ASON)", June 2002. 


GETTA aL] ITU-T Draft Rec. G.7715.1/Y.1706.1, "ASON Routing 
Architecture and Requirements for Link State 
Protocols", November 2003. 


[G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the 
Automatically Switched Optical Network (ASON)", 
June 2006. 

[M.3016] ITU-T Rec. M.3016.0, "Security for the Management 


Plane: Overview", May 2005. 


Papadimitriou, et al. Informational [Page 17] 


RFC 4652 Evaluation of Routing Protocols against ASON October 2006 


Appendix A. ASON Terminology 
This document makes use of the following terms: 


Administrative domain (see Recommendation G.805): For the purposes of 
[G.7715.1], an administrative domain represents the extent of 
resources that belong to a single player such as a network operator, 
a service provider, or an end-user. Administrative domains of 
different players do not overlap amongst themselves. 


Control plane: Performs the call control and connection control 
functions. Through signaling, the control plane sets up and releases 
connections and may restore a connection in case of a failure. 


(Control) Domain: Represents a collection of (control) entities that 
are grouped for a particular purpose. The control plane is 
subdivided into domains matching administrative domains. Within an 
administrative domain, further subdivisions of the control plane are 
recursively applied. A routing control domain is an abstract entity 
that hides the details of the RC distribution. 


External NNI (E-NNI): Interfaces are located between protocol 
controllers between control domains. 


Internal NNI (I-NNI): Interfaces are located between protocol 
controllers within control domains. 


Link (see Recommendation G.805): A "topological component" that 
describes a fixed relationship between a "Subnetwork" or "access 
group" and another "subnetwork" or "access group". Links are not 
limited to being provided by a single server trail. 


Management plane: Performs management functions for the Transport 
Plane, the control plane, and the system as a whole. It also 
provides coordination between all the planes. The following 
management functional areas are performed in the management plane: 
performance, fault, configuration, accounting, and security 
management 


Management domain (see Recommendation G.805): A management domain 
defines a collection of managed objects that are grouped to meet 
organizational requirements according to geography, technology, 
policy, or other structure, and for a number of functional areas such 
as fault, configuration, accounting, performance, and security 
(FCAPS), for the purpose of providing control in a consistent manner. 
Management domains can be disjoint, contained, or overlapping. As 
such, the resources within an administrative domain can be 
distributed into several possible overlapping management domains. 
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The same resource can therefore belong to several management domains 
simultaneously, but a management domain shall not cross the border of 
an administrative domain. 


Subnetwork Point (SNP): The SNP is a control plane abstraction that 
represents an actual or potential transport plane resource. SNPs (in 
different subnetwork partitions) may represent the same transport 
resource. A one-to-one correspondence should not be assumed. 


Subnetwork Point Pool (SNPP): A set of SNPs that are grouped together 
for the purposes of routing. 


Termination Connection Point (TCP): A TCP represents the output of a 
Trail Termination function or the input to a Trail Termination Sink 
function. 


Transport plane: Provides bi-directional or unidirectional transfer 
of user information, from one location to another. It can also 
provide transfer of some control and network management information. 
The Transport Plane is layered; it is equivalent to the Transport 
Network defined in G.805 Recommendation. 


User Network Interface (UNI): Interfaces are located between protocol 
controllers between a user and a control domain. Note: There is no 
routing function associated with a UNI reference point. 


Appendix B. ASON Routing Terminology 
This document makes use of the following terms: 


Routing Area (RA): An RA represents a partition of the data plane, 
and its identifier is used within the control plane as the 
representation of this partition. Per [G.8080], an RA is defined by 
a set of sub-networks, the links that interconnect them, and the 
interfaces representing the ends of the links exiting that RA. An RA 
may contain smaller RAs inter-connected by links. The limit of 
subdivision results in an RA that contains two sub-networks 
interconnected by a single link. 


Routing Database (RDB): Repository for the local topology, network 
topology, reachability, and other routing information that is updated 
as part of the routing information exchange and that may additionally 
contain information that is configured. The RDB may contain routing 
information for more than one Routing Area (RA). 
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Routing Components: ASON routing architecture functions. These 
functions can be classified as being protocol independent (Link 
Resource Manager or LRM, Routing Controller or RC) and protocol 
specific (Protocol Controller or PC). 


Routing Controller (RC): Handles (abstract) information needed for 
routing and the routing information exchange with peering RCs by 
operating on the RDB. The RC has access to a view of the RDB. The 
RC is protocol independent. 


Note: Since the RDB may contain routing information pertaining to 
multiple RAs (and possibly to multiple layer networks), the RCs 
accessing the RDB may share the routing information. 


Link Resource Manager (LRM): Supplies all the relevant component and 
TE link information to the RC. It informs the RC about any state 
changes of the link resources it controls. 


Protocol Controller (PC): Handles protocol-specific message exchanges 
according to the reference point over which the information is 
exchanged (e.g., E-NNI, I-NNI) and internal exchanges with the RC. 
The PC function is protocol dependent. 
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